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Abstract 

We propose a method for engineering security protocols that are aware of timing aspects. 
We study a simplified version of the well-known Needham Schroeder protocol and the complete 
Yahalom protocol, where timing information allows the study of different attack scenarios. We 
model check the protocols using UPPAAL. Further, a taxonomy is obtained by studying and 
categorising protocols from the well known Clark Jacob library and the Security Protocol Open 
Repository (SPORE) library. Finally, we present some new challenges and threats that arise 
when considering time in the analysis, by providing a novel protocol that uses time challenges 
and exposing a timing attack over an implementation of an existing security protocol. 
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1 Introduction 

The communication via a shared medium, like the Internet, is inherently insecure: anyone has 
access to en route messages and can potentially eavesdrop or even manipulate the ongoing com¬ 
munication. Security protocols are distributed programs specifically designed to achieve secure 
communication over such media, typically exchanging messages built constructed using crypto¬ 
graphic operations (e.g. message encryption). 

Security protocols are difficult to design correctly, hence their analysis is critical. A particularly 
successful model to analyze security protocols is the Dolev Yao model m, in which the attacker is 
assumed to have complete control over the network. Also, the model assumes ideal cryptography, 
where cryptographic operations are assumed to be perfect. The Dolev Yao model is attractive 
because it can be easily formalized using languages and tools based on formal methods. More¬ 
over, the model has an appropriate level of abstraction, as many attacks are independent of the 
underlying details of the cryptographic operations and are based only on combinations of message 
exchanges plus knowledge gathered by the attacker during the execution. 

Typically, Dolev Yao methods for formal verification of security protocols (among the propos¬ 
als mmm) do not take time into account, and this choice simplifies the analysis. However, 
security protocols, like distributed programs in general, are sensitive to the passage of time. Re¬ 
cently, consideration of time in the analysis of security protocols has received some attention (see 
Related Work below), but this attention has been focused mostly on timestamps. 

In this paper 1 we develop an analysis model for security protocols that explicitly takes into ac¬ 
count time flowing during the execution of a protocol. In general, in the design and implementation 
of a security protocol two aspects of timing must be considered at some stage: 

1. Time can influence the flow of messages. For instance, when a message does not arrive in a 
timely fashion (i.e. timeouts ), retransmissions or other actions have to be considered. 

2. Time information can be included within protocol messages (e.g. timestamps). 

*Contact author’s email is ricardo.corinOutwente.nl. 

x An earlier version appeared in m 


i 



Consider first (1) above. In general, the influence of time on the flow of messages is not usually 
considered by current state of the art methods for analysing protocols. However, we believe it to be 
crucial because (i) Even if the abstract protocol does not decide what action to take at a particular 
moment of the execution (e.g. in the case of timeouts), the actual implementation will eventually 
have to consider these issues anyway; (ii) The efficiency and security of the implementation depends 
critically on these specific decisions; and (iii) The timing of message flows in a protocol can be 
exploited by an attacker. 

Now consider item (2) above. There, we believe that making judicious use of timing information 
in a protocol has received attention but mostly in the limited setting of using time stamps as 
opposed to nonces. However, time information can be used to influence message flows as well, as 
we illustrate in Section [6] 

Contributions Our study covers several issues in the study of time in security protocols. 

• Firstly, in Section[2]we study which kinds of timing issues, like timeouts and retransmissions, 
may arise in the study of security protocols. We then proceed in Section 0 to present a 
method for the design and analysis of security protocols that consider these timing issues. 
The method is based on modelling security protocols using timed automata [3]. In support 
of the method we use UPPAAL 0| as a tool to simulate, debug and verify security proto¬ 
cols against classical safety goals like secrecy and authentication, in a real time scenario , 
using reachability properties. As examples, we analyse a simplified version of the Needham 
Schroeder protocol EH and the full Yahalom protocol g in Section H 

• Secondly, in Section 0 we categorize all the protocols from the Clark and Jacob library and 
the SPORE library into different (more abstract) patterns of message flows with timeouts. 
We then analyse each abstract pattern, independently of the actual protocols, and establish 
their timing efficiency and security. 

• Finally, in SectionHwe illustrate some novel opportunities and difficulties that appear when 
considering time in the design and analysis of security protocols: 

— In Section ffi.1 I we give an example protocol that accomplishes authentication by exploit¬ 
ing the timeliness of messages. The protocol uses time in a conceptually new way, by 
employing time challenges as a replacement for nonces. 

— As a second example of a novel difficulty in Section 16.21 we describe how timing at¬ 
tacks DU can be applied to security protocols, by describing an attack over Abadi’s 
private authentication protocol [2] ■ Although these protocols can be modelled as timed 
automata, thus permitting general verification, we leave the detailed verification as fu¬ 
ture work since for this we need a model checker that is also probabilistic (like m or 
my our nondeterministic intruder of UPPAAL is too powerful, since it can always 
guess correctly times and values even if the probability of guessing is negligible. 

2 Timeouts and Retransmissions 

To illustrate how time influences the analysis of security protocols (even when it does not explicitly 
use timing information), consider the following protocol written in the usual notation. 

1 .A —► B : Mab 
2. B — > A : Mb a 

Here, first A sends message Mab to B 1 and later B sends message Mba to A. This high-level 
view does not consider timing. To consider time, we first need to assume that both A and B have 
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Figure 1: Left’. Timeouts (i) typical (ii) windowed; Right: timeout actions (iii) chained abort and 
(iv) retransmission 


timers. In this paper, we do not require timers between parties to be synchronised (see below for 
a discussion). The next step consists in distinguishing the different operations that occur, with 
their respective times. In Step 1, it takes some time to create Mab■ The other operation that 
takes time is the actual sending of the message, ie. the time it takes Mab to travel from A to B. 
This transmission time is unbounded, since the message may be lost or intercepted, and therefore 
A may need to timeout: After A sends Mab, she starts a timer that will timeout if Mba (Step 2 
of the above protocol) is not received after some waiting, say tA (Figure Q] (i)). Clearly, tA should 
be greater than the time of creating Mba, phis the average time of sending both Mab and Mba- 
In general, A does not need to start waiting for a response immediately after sending a message; 
for instance, A could hibernate (or start doing another task) for some time sa before beginning 
to expect the response Mba■ This results in a windowed timeout (Figure Q (**))• Typically, the 
values for sa and tA depend on implementation details. However, an implementation independent 
quantitative analysis could already give an early indication of what attacks can be mounted for 
some values that are no longer possible for others (eg. a smaller tA and a larger sa)- 

Another issue that is not considered either in previous approaches is that the action to be 
taken when a timeout occurs is sensitive. Typically, the implicit assumption is that the protocol 
should abort, as it is the case in Figure ^ CO- This means that the protocol party that reaches the 
timeout deduces that a fault has happened. However, aborting may not consist only of stopping 
execution altogether. For example, if we consider protocols with several parties, we may wish that 
when a party timeouts it also communicates its decision to abort to other, still active parties. For 
instance, consider the following protocol: 


1. A - 

4 B 

Mab 

A starts timer expecting Mba 

2. A- 

-4 S 

Mas 

S starts session timer 

3. B - 

4 A 

Mba 



Here, if A times out on Step 2, she could communicate the abort decision to S, as shown in in 
Figure 0 (iii). 

Aborting execution is not the only feasible action to perform after a timeout ESI, and in 
principle protocols could successfully execute when messages do not arrive at certain moments. 
Even if we do assume that a fault occurred, aborting may not be the best choice: sometimes, 
message retransmission is a better, more efficient and also more realistic option, as depicted in 
Figure ^ (iv). In this case, a question which arises is whether to retransmit the original message 
(Mab for Figure 0 (iv)), or to recompute some parts before resending the message. Here, the 
tradeoff is, as usual, between efficiency versus security. 

Time information can also be included in the contents of Mab and Mba ■ A typical value to 
include is a timestamp, to prevent replay attacks. However, this requires secure clock synchroni¬ 
sation of A and B , which is expensive (see Mills m for a security protocol to achieve this). In 
fact, this is the reason for which Bellovin et al. recommend to switch to nonces in the Kerberos 
protocol 0. Recently, the analysis of security protocols using timestamps has received consider- 
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able attention from the research community (see Related Work in Section Q. Therefore, in this 
paper we do not pursue this direction. 


3 A Method for Analysing Security Protocols 

We use timed automata [21 to model protocol participants, and this has several advantages. Firstly, 
our method requires the designer to provide a precise and relatively detailed protocol specification, 
which helps to disambiguate the protocol behaviour. Secondly, timing values like timeouts need to 
be set at each state, while retransmissions can be specified as transitions to other protocol states. 

Once modelled as timed automata, the protocol can be fed to the real time model checker 
UPPAAL, which allows the protocol to be simulated and verified. The simulation provides the 
designer with a good insight of the inner workings of protocol, and already at this stage specific 
timing values like timeouts can be tuned. Then the designer can proceed with verification of 
specific properties. As usual in model checking, the verification of the protocol with UPPAAL is 
automatic. 

The resulting timed automata model is an informative and precise description of the secu¬ 
rity protocol, and thus, it provides a practical way to strengthen implementations while keeping 
efficiency in mind. 

As a third and final step we propose to transfer timing information back to the high level 
protocol description. This serves to highlight the role of time in the implementation, but also (as 
we will demonstrate in Section Oil . to make timing an integral aspect of the protocol design. 

3.1 Timed Automata and UPPAAL 

In this paper, the timed automata of Alur and Dill are used for modelling 0. In general, timed 
automata models have an infinite state space. The region automaton construction, however, shows 
that this infinite state space can be mapped to an automaton with a finite number of equivalence 
classes (regions or zones) as states 0 . Finite-state model checking techniques can then be applied 
to the reduced, finite region automaton. A number of model checkers for timed automata is 
available, for instance, Kronos j22 and UPPAAL 0. 

Parallel composition of automata is one of the main sources for expressiveness. This operation 
allows to decompose complex behaviour, thus supporting transparent modelling. When compos¬ 
ing automata in parallel, we need also to provide some form of communication. For the timed 
automata we use in this paper, communication comes in form of hand-shake synchronisation. Two 
parallel automata can share a synchronisation channel, i.e. both have a transition labelled with 
a complementing channel name, e.g. synchronise! in the example of Figure 0 These transitions 
may only be taken together, at the same moment. In FigurcElwe see an example for a transition, 
labelled by a guard that has to be true when the transition is taken, a synchronisation channel, 
and a variable update. 

Data transmission is typically modelled by a synchronisation, where global variables are up¬ 
dated. These global variables contain the data that are transmitted. 



var_v>const_c 
synchronise! 
var_w: =var_w+1 



Figure 2: Example transition with guard, synchronisation and update 


4 



^ Initiator ^ 

L_ J 

decrypt {nb} pk ^~ 



generate nb 
ncrypt nb,pk(a ) 


Figure 4: Structure of our UPPAAL Model 


Timed automata extend “classical” automata by the use of real-valued clock variables. All 
clock variables increase with the same speed. For timed automata we make a difference between 
a state and a location: a state is a location where all clocks have a fixed value. In this sense a 
location symbolically represents an infinite set of states, for all the different clock valuations. In 
Figure^an elementary fragment of timed automata is shown. When the transition from location 
I to location II takes place, the clock clock is reset to 0. Location II may only be left at time D. 
where D is a constant. The invariant clock<=D at location II enforces that the transition to III has 
to be taken at time D. 


o 


clock:=0 


II 

clock<=D 


clock==D 




Figure 3: Basic timed automaton fragment with a clock and a constant D 

Typically, the initial location of an automaton is denoted by a double circle. We also make use 
of committed locations, which have the property that they have to be left immediately. In most 
cases committed locations are used to model a sequence of actions with atomic execution. 

The properties verified by the model checker of UPPAAL are reachability properties, like “there 
is a state where property p holds reachable from the initial state”, or the dual “in all reachable 
states property p holds”. The latter is falsified if the model checker finds a state that does not 
satisfy p. In this case a diagnostic trace from the initial state to the state that does not satisfy p 
is produced by the model checker; it serves as counterexample. 

We use this mechanism to find attacks. If we can characterize for example the fact that some 
secret is not secret any more as a propositional property, and the model checker finds a state where 
this property holds, the diagnostic trace describes a sequence of actions that leads to this state, 
which gives precisely the attack. 

Note that in this context verification comes very much in the guise of debugging. Finding an 
attack requires an adequate problem model. Not finding an attack increases the confidence in the 
modelled protocol, but does not exclude that attacks could be found in other models for the same 
protocol. 

3.2 Overview of the UPPAAL Model 

Let us now describe the general form of our model, in some detail. We model the protocol par¬ 
ticipants (initiator, responder, etc) and the intruder as timed automata. Additionally, we model 
cryptography as another automaton, the cryptographic device , which acts as an impartial party 
that regulates the access to data. In Figure 0 we illustrate a setting consisting of one initiator and 
one responder. Here, boxes in bold represent our general intruder and the cryptographic device, 
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while dashed boxes represent the actual initiator and responder. These participants use the cryp¬ 
tographic device to perform operations, but communicate through the intruder (thus the intruder 
is identified with the network itself, obtaining a Dolev Yao like intruder m). Our modelling is 
modular , and allows us to “plug in” different participants (eg., in the analysis of the Yahalom we 
add a server ), while the bold boxes, ie. the intruder and the cryptographic device, are the core 
model. 

While modelling security protocols as timed automata in UPPAAL, we will focus on modelling 
the times required by the principals to encrypt and decrypt values (and generate nonces), but not on 
the actual time that takes the sending (transmission times are assumed to be unknown). Therefore, 
for our results to be useful, we assume that computing times (e.g. cryptographic operations) are 
not negligible w.r.t. communication times, and thus choices for timeout values depend both on 
communication and computing times. 

3.3 Modelling Cryptography 

The automaton for a cryptographic device is presented in Figure 0 This cryptographic device 
performs nonce generation and public key cryptography. Later we also use a device for symmetric 
cryptography, which can be obtained from the one in Figure[S]m a straightforward manner. In fact, 
our method allows different cryptographic devices to be plugged in as needed (eg. to add hashing). 
Basically, the device model is a shared table containing pairs of plaintexts and keys. The first service 
of the cryptographic device is to provide fresh nonces to the protocol participants (and also the 
intruder). The process of nonce generation is started via synchronization on the gen_nonce channel. 
To model the new nonce creation, the local variable gennonce is incremented with the constant 
seed plus the value of paraml that includes the ID of the requesting participant (this ensures that 
initial generated nonces differ from each other). The number of possible nonces is bounded by 
ensuring that gennonce is always smaller than a fixed constant MAX. After synchronization, a 
global result variable is updated with a generated nonce, and the device finishes by synchronizing 
on the finish_nonce channel. 

Encryption and decryption are modelled by two local arrays to the cryptographic device, namely 
plain and key. When a party wants to encrypt some value d with key fc, it synchronises with the 
device via the channel start_encrypt. If the device has still room in its tables, it stores d in the 
plain array and k in the key array. As a result, it sets in the global variable result the index in 
which d and k reside in the arrays. This index is the “ciphertext”. Upon decryption, the ciphertext 
is provided to the cryptographic device, which then checks that the provided key is correct: Since 
we model public-key encryption, the private key of a public key k is simply modelled as a function 
/ s.t. f(k) > MAX , so that private keys do not clash with generated nonces and hence are never 
known by the attacker simply by guessing. In this simple case we simply let f(k) = lOfc, which 
since only one nonce is needed by the participants in the example protocol of Section 14.11 gives 
enough room for the attacker to generate nonces. 

State constructions Now that we have the cryptographic device, an honest principal can use 
different state constructions to perform cryptographic operations. In Figurc|S]we show the different 
kinds of state constructions used in our models, which designers should use as building blocks for 
the representation of protocol participants. 

In the upper left of Figure [fj] we see the building block for nonce generation. Here, a protocol 
participant first resets the clock t, assigns its identity to variable par am (used by cryptographic 
device to provide different nonces to different participants) and then fires via the genjnonce channel. 
Then the participant enters a state in which it waits until the time of nonce generation happens 
(time_gennonce), synchronises via the finishjnonce channel and obtains the return value via 
variable result. Encryption and decryption are analogous, and only differ in that they use two 
parameters paraml and param2 (for plaintext and key in the former, and ciphertext and key in the 
latter). 
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GEN_NONCE: 


ENCRYPT: 


DECRYPT: 


= © 
© 


J gen_nonce! 
t:=0, 

param:=ID 

t<= 

time_gennonce 

flnish_nonce? 

t>=time_gennonce 

var:=result 

start_encrypt! 


finish_encrypt? 

t:=0. 


t>=time encrypt 

paraml:=plain 

time_encrypt 

var:=result 

param2:=key 

_ 


start_decrypt! 


finish_decrypt? 

t:=0, 


t>=time decrypt 

paraml:=cipher 

time_decrypt 

var:=result 




-© 




param2:=key 

State constructions: nonce generation (above), encryption (middle) and decryption 
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Figure 7: Schema for the timed automaton for the Intruder 


3.4 Modelling the Adversary 

The intruder, presented in Figure Q works basically as a Dolev Yao intruder m- The intruder 
models the network itself, by acting as an intermediary of communication between the initiator 
and responder. This is modelled by letting the intruder synchronise on both channels initjmsg 
and respjmsg. Upon synchronising by receiving a message, the intruder moves to state (SINT1), 
where it saves the message msg in its local variable data and resets an index variable i which 
bounds the total number of actions allowed to do before continuing execution. Then, the intruder 
moves to state (SINT3), where it makes a nondeterministic choice for an action. More precisely, 
it can decide to: 

- Choose an identity in its local variable pk (State SINT4) 

- Encrypt a value (State SINT5) 

Decrypt a value (State SINT6) 

- Generate a nonce (State SINT7) 

- Save variable data as message msg. 

The intruder can then continue to perform these actions, choose to send a message or simply block 
a message and continue the execution. Moreover, the intruder can also delay arbitrarily a message, 
by waiting in state (SINT2). 

Note that the intruder is independent of the actual protocol under study, and hence it is generic 
to analyze protocols using public key encryption (although this intruder is not able to concatenate 
messages; we extend it in the next section). 


4 Analysing Protocols 

We first consider a simple protocol to illustrate our technique. Later, we move on to analyse the 
more complex Yahalom protocol. 

4.1 An Example Protocol 

In this section we study and model in UPPAAL a simplified version of the Needham Schroeder pro¬ 
tocol, thoroughly studied in the literature (see eg. [23). Differently from the Needham Schroeder 
protocol whose goal is to achieve mutual authentication, our simpler protocol aims at authenticat- 
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ing the initiator A to a responder B only (we do not lose generality here, this is just a simplification 
to improve presentation). The protocol is as follows: 

1 .A-+B : A 

2 .B^A : {N b } Ka 

S.A^B : {N b } Kb 

In the first message, the initiator A sends a message containing its identity to the responder 
B. When B receives this message, it generates a nonce N B , encrypts it with the public key Ka of 
A and sends it back to A. Upon receipt, A decrypts this message with her private key, obtains the 
nonce N B , reencrypts it with the public key K B of B and sends it back to B. 

We can now move on to describe the actual initiator, responder and intruder. Both the initiator 
and responder have local constants time_out, which represent their timeout values. Also, the initia¬ 
tor, responder and intruder have local constants time_gennonce, time_encrypt and time_decrypt 
that represent the time required to generate a nonce, encrypt a value or decrypt a value, respec¬ 
tively for each principal. 

The automata for the initiator and responder of our simple protocol presented above are given 
in Figure 0 (the dashed transitions of the responder correspond to retransmissions, discussed in 
Section Fl. 1.211 . The initiator A starts her execution when activated via channel start (State SIO). 
The actual identity of the initiator role is set via the global variable init_id (this and other role 
variables are chosen by the Init automaton, described below). The initiator saves init_id as the 
first message (see protocol message 1). Then, the initiator starts her protocol execution, by firing 
via the channel initjmsg. After this, the initiator starts a clock t and waits for a response, or until 
t reaches time_out (State SI2). If the timeout occurs, the protocol is aborted (a retransmission 
at this point would be equivalent to restart the protocol). If a response is received before the 
timeout via the initjmsg channel, A tries to decrypt the received message msg. This takes time 
time_decrypt for the initiator. After the decryption, the initiator reencrypts the obtained nonce 
(stored in result) and finally sends the last message via the initjmsg channel, setting to true its 
local boolean variable finish. 

The responder automaton B works similarly to the initiator. After receiving the start signal, 
B waits for the message containing the claimed identity of A (State SRI). When received, B saves 
the first message in the local variable claimed_id. After this, B generates a nonce by contacting 
the cryptographic device. When ready (State SR3), B encrypts the nonce with the value received 
in Message 1 (we identify identities with public keys). After finishing the encryption (State SR4), 
the message is sent and B starts to wait for a response (State SR5). If an answer comes before the 
timeout, B decrypts the message and checks that the challenge is indeed the one B sent. If so, the 
local boolean variable finish is set to true. 

4.1.1 Verification 

We wish to verify that our simple protocol indeed accomplishes authentication of A to B. To 
this end, we will model check one session of the protocol containing one initiator, one responder 
and one intruder. We use a special Init automaton that instantiates the initiator and responder 
with identities (like A, B and /), and then starts the execution run by broadcasting via the start 
channel. The init automaton is given in Figure [5) 

The property we check, AUT , is shown in Table 1. AUT states that if we reach a state in 
which the responder has finished executing but the claimed id (corresponding to the first message 
of protocol) does not coincide with the actual identity of the initiator, the protocol is flawed. 
Indeed, a state in which the initiator can “lie” and still force the responder to finish means that 
authentication is violated. This is one of the possible forms of authentication failure. It is outside 
the scope of this paper to illustrate different authentication flaws (see Lowe m and Cremers et 
al. |l2| for more on authentication notions). 
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Figure 8: Schemas of timed automata for the Initiator (top) and the Responder (bottom) 
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AUT = E <> Responder.finish and 

Responder.claimed_id! = resp_party 
AUTy = E <> Initiator.f inish and 

Initiator.ticks < (Responder.time_encrypt 
+Responder.time_gennonce + Server.time_encrypt * 2 
+Server.time_decrypt) — 1 


Table 1: UPPAAL properties 
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Table 2: A man-in-the-middle attack (left) and a replay attack (right) 


If we use a long timeout for B , i.e. 

£>.time_out > 7ntruder.time_decrypt + 7niruder.time_encrypt + Atime_encrypt + Atime_decrypt 

here UPPAAL finds a man-in-the-middle attack, presented on the left hand side of Table □ This 
attack is similar to Lowe’s attack m, in which an attacker fools B into thinking he is commu¬ 
nicating with A, while in reality A only talks to 7. Of course, we could patch the protocol as 
Lowe did. But, in the context of time, it is interesting to model-check the protocol with a tighter 
timeout, ie. 7?.time_out < Intruder.time_decry]?t +Intruder.time _encrypt + A.time_encrypt + 
Atime_decrypt. When this constraint is verified, the man-in-the-middle attack vanishes. Of 
course, we cannot pretend that B knows the intruder’s times of encryption and decryption. Nev¬ 
ertheless, B can set 7?.time_out = Atime_encrypt + Atime_decrypt, leaving no space for any 
interruption. 

A second attack which is independent of timeouts (even if we set B.time_out = 0!) was also 
found by UPPAAL; this time, the vulnerability is much simpler. We report it on the right hand side 
of Table □ This attack corresponds to a “reflection” replay attack m- This attack occurs when 
the intruder simply replies BA message. The attacker fools B into thinking its communicating with 
himself, while it is not true in reality. Interestingly, suppose we change message 3 of the protocol 
to 3'. A —> B : {Nb + 1 }k b - Now, the above replay attack is prevented, since message 2 is not 
valid as message 3 anymore. Of course, a patch a la Lowe for both also prevents both problems: 

1. A —> B : A 

2 .B^A : {B, N b } Ka 

3 .A^B : {N b }k b 

Having find confirmation that our framework is capable of finding untimed attacks (and thus 
confirming known attacks), we proceed to provide a good baseline to study extended security 
protocols with timing issues, like timeouts and retransmissions. 

4.1.2 Retransmissions 

Consider again the automaton for the responder, given in Figure |H1 In state SR4, the responder 
sends the challenge {Nb}k a , and waits for a response in state SR5. If the response does not arrive 
before the timeout, the responder simply aborts. Now we consider possible retransmissions that 
allow the protocol to recover and continue its execution. With timed automata, retransmissions 
are easy to model by adding transition arrows from state SR5 to previous states of the automaton 
(the dashed lines in FigurelBJ); These transitions are guarded, allowing to perform the action only 
when the timeout is reached (ie., t >= time.out). A further refinement not explored here would 
be to add counters so that the number of retransmissions can be limited before aborting. 

We consider two potential target states for the timeout of the Responder in SR5, namely states 
SR3 and SR2. Choosing the former corresponds to retransmitting the exact same message that 
was sent before, {N b }k a - On the other hand, linking the retransmission arrow to SR2 corresponds 
to recomputing the whole message, by creating a new nonce N' B and sending {N' b }k a - 
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We implemented both strategies in our UPPAAL model. As can be expected, retransmitting the 
exact message once has the effect of duplicating the timeout for B , and thus the man-in-the-middle 
attack becomes possible even for tight timeout values. On the other hand, recomputing the whole 
message preserves the security of the protocol, at a higher computational cost. This evidences that 
indeed these design decisions are important for both security and efficiency, and a careful analysis 
can help to choose the best timeouts and retransmissions for a practical implementation. 

4.2 A Real Protocol 

Having illustrated our approach with a simple example we now study a more realistic protocol, the 
Yahalom protocol 0- This protocol aims at authentication of A and B as well as key distribution 
of A and B using a shared server S with whom both A and B share secret keys Kas an d Kbs- 
Our choice is based on the fact that Yahalom is a complex and strong protocol, with no known 
attacks over it (However, a modification proposed by Abadi et al. [3J has a known type-flaw attack). 
Our aim is to study the protocol in more detail (and thus closer to an implementation) with timing 
information. The protocol is as follows: 


1 . A- 

-> B 

A,N a 

2 . B 

-4 S 

B, { n b,A 7 Na}kb S 

3 . S- 

■+ A 

{B, Kab , N a , N b }k as , { 4 , Kab, Nb}k b 

4. A- 

■> B 

{A, Kab,N b }kbs’{Nb}k A b 


Here we use symmetric encryption, and key Kxy is shared between X and Y . 

To model concatenation in an efficient way, we gathered several message components into a 16 
bit field, thus keeping the state space as small as possible. In our case, we assume that nonces 
have 4 bits, principal id’s 2 bits and keys 4 bits. To access these values, we use bit-wise and 
with appropriate masks, and (left,right) bit shifts. Our intruder has also the capability to do the 
shifts and mask, and we also removed the “public key” choice from the intruder of Figure 0 We 
have modelled the protocol in UPPAAL (the initiator, responder, server and intruder are shown 
in Figures EH and fTTl) . 

As we did with the previous protocol, first we check whether authentication of A to B could 
be falsified, using property AUT from Table Q This property is not satisfied, confirming that 
Yahalom is secure. Now we move to study time sensitive issues. 

There are two places in which timeouts and retransmissions can occur in this protocol. The 
first one is in Message 1: After A sends her message, she starts a tinier waiting for message 3. Now, 
suppose that a timeout occurs, and A wants to retransmit her message. We can be confident that 
resending the same nonce Na will not affect security, since in any case it was already sent in the 
clear in the first time. However, an interesting timing issue arises here. An answer that is received 
too early by A could be suspicious, because some time must pass while B talks to S. If A knows 
B’ s and S’ s encryption and decryption times, A could even deliberately “hibernate” (eg. to save 
energy) until the response is likely to arrive (this models a windowed timeout, see Figure ^ (**))■ 
We model checked this property by measuring the time after A sends her message, and a response 
arrive (we count ticks, the dashed loop transition of the initiator in Figure HDD- The specified 
property is AUT y , shown in Tabled This property is not satisfied, confirming that there is no way 
that the initiator can receive a valid answer before the time required by the responder and server 
to process A’s request. In an implementation, it is reasonable for A to set a timeout like above, 
since it is realistic to assume that A can know the responder and server’s times of encryption and 
decryption. 

The second timeout is set by B after sending his message at step 2. If a timeout occurs, 
the retransmission decision is more delicate: It is not clear whether B should resend the original 
message, should recompute Nb or whether B should abort, since clearly Na cannot be recomputed. 
Intuitively, Ng could be reused. We modelled in UPPAAL the retransmission of the exact message 
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Figure 10: Timed automata schemas for the Yahalom Initiator (top) and responder (bottom) 


(as the dashed transition of the responder in Figure ITTill . When we model check again property 
AUTy , we obtain that it is still unreachable, confirming that in that case an efficient retransmission 
of the same message 2 by B is secure. 

However, by observing the messages flow, we know that if B timeouts then it is very likely that 
A has also reached its timeout and aborted (see FigureE(w))- This mainly happens because since 
A is unsure whether B is alive or not, and thus A’s timeout needs to be tight. If A knew that 
B is alive and waiting for an answer from S , then A could extend its timeout. We then sketch a 
more efficient implementation in Figure 1121 in which at Message 2 B also sends a special subm 
message notifying A of the submission to S. Then A can extend its timeout with more confidence 
(the second dashed line in Figure IT2l) . In the case subm is never received by A, she can send an 
abort message to B. Of course, in this simple model the attacker can also send this messages, 
thus performing denial of service attacks; in any case, our attacker is powerful enough to stop 
communication altogether. 

In summary, for the Yahalom protocol we obtain that retransmitting for the responder is secure, 
and also that the initiator can be implemented to efficiently “hibernate” a safe amount of time 
before receiving a response. 


5 Taxonomy of Message Flows in Security Protocols 

The flow of messages of many protocols follow a small set of specific patterns. By exploring the 
well known Clark Jacob library of authentication protocols and the Security Protocols Open 
Repository (SPORE) E, we were able to categorize the protocols in four categories, as shown 
in Figure ED To each pattern, we add the corresponding timeouts, and analyze their impacts 
on security and efficiency. For the original references of the protocols, the interested reader may 
consult the Clark Jacob library 0 and the SPORE library [I . 
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Figure 11: Timed automata schemas for the Server (top) and Intruder (bottom) 
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Figure 12: An more detailed implementation of Yahalom 
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Not shown in this categorization are non-interactive protocols which do not wait for messages 
and thus do not require timeouts. In this category fall the Wide Mouthed Frog protocol, the 
CCITT X.509 simple pass protocol and the CAM protocol for mobile IP. 

First, we discuss the simplest pattern in Figure H3I (i). This is a three-message exchange with 
two participants. This pattern is the simplest and also the most secure one from timing point 
of view, since timeouts can be set tight, due to the ping-pong nature of the exchanges. To this 
pattern correspond both the example protocol of Section UTI and the one in Section lfTTl and also the 
protocols CCITT.509 three pass, the Shamir Rivest and Adleman Three-Pass protocol, the ISO 
XXX Key Three-Pass (and their repeated protocols), the SmartRight view-only protocol (from 
SPORE) and the Diffie-Hellman key exchange protocol. With a fourth message from B to A in 
the same fashion we find the Andrew Secure RPC protocol. Adding a third participant S, but still 
doing ping-pong exchanges, we can add the Needham Schroeder symmetric key protocol and the 
Denning Sacco protocol. 

Secondly, we identify three-party protocols, in which a server S also takes part in the communi¬ 
cation ('Figure l*HH I'mD but ping-pong exchanges are not anymore used. This pattern is potentially 
unsafe and inefficient for A, since she has to wait until a long timeout as elapsed after the first 
message before receiving an answer from S. This is due to the fact that three messages have to 
be exchanged after A’s initial message. By consulting again the Clark and Jacob library and the 
SPORE repository, we see that the Otway Rees protocol, the Gong mutual authentication pro¬ 
tocol, the Woo-Lam mutual authentication protocol, the Carlsen protocol, and finally the Kehne 
Schoenwalder Langendorfer (KSL) protocol all fall in this category. Adding ping-pong exchanges 
before and after the exchanges of Figured ( ii ) we find the Needham Schroeder Public key proto¬ 
col. Adding a ping-pong exchange before Figure ITTil (i.A. and removing the last exchange gives us 
the SPLICE/AS protocol. 

Thirdly, we see a pattern to which only the Kao Chow protocol belongs in Figure fHflfm'l. This 
pattern is however better than ( ii ), since shorter and fewer timeouts are used: A needs to wait for 
the timeout corresponding to only two messages (instead of three as in (ii)), and B has to wait for 
only one timeout (comparing to two timeouts in (**)). 

Finally, in Figured! (iv) we see the last pattern. This pattern is worse than (Hi) since B needs 
to wait longer (for two messages instead of one in (Hi)). However, it is unclear whether it is better 
than (ii ), which uses two timeouts of one message each: the actual efficiency and security depends 
on the actual timeout values used in each case. This category is inhabited by the Yahalom and 
Neuman Stubblebine protocols. 
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B A 








B 


S A 


B A 


B 


i< 


(i) 


(ii) 


(in) 


(iv) 


Figure 13: Typical message flows for authentication protocols 


This taxonomy shows how authentication protocols can be categorized into a handful of pat¬ 
terns. The efficiency and security that an implementation of a protocol will have depends on which 
pattern the protocol follows, and thus it is useful to consider the patterns in isolation from the 
actual protocols. In this paper we do not pursue this further, although as future work it would be 
interesting to further analyze these abstract timing patterns induced from security protocols. 
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6 Beyond Model Checking: Novel Issues Considering Time 

So far our method has been used for analysis purposes, ie. to model, classify and debug security 
protocols as a source of hints for the improvement of the protocol implementations. We now 
explore some ideas to improve the protocols themselves, and also present the threat of a more 
subtle attack, based only on timing. 

6.1 Using Time as Information: Timed Challenges 

Sometimes it can be useful to include other timed information than timestamps, even if the clocks 
are not synchronised. Consider the following protocol, obtained by omitting the encryption of the 
last message of the (patched) protocol of Section ITT! 

1. A—> B : A 
2 .B^A : {B,N b } Ka 
3 . B : N b 

Even though N B is now sent in the clear, this protocol still achieves authentication of A to B , 
although now the nonce obviously cannot be regarded as a shared secret. Still, the intruder can 
prevent a successful run of the protocol (eg. by intercepting message 3), hence the protocol is as 
strong as it was before in this respect. 

Imagine now a situation in which there is a link from A to B in which data can be sent very 
fast, but at a high cost per bit sent. For example, think that the high cost of sending information 
comes from the fact that we have devices with a very limited amount of energy, like wireless sensor 
networks for instance. Alternatively, in some networks, operators charge according to quality of 
service, and many networks have asymmetric links (eg. Cable modem and ADSL). 

Assume therefore that, sending N B in message 3 is expensive and not desirable. We propose a 
solution based exclusively on using time as information. Let Sab be the average time it takes for 
a message to be sent from A to B, and analogously Sea- Then consider the “timed” variant of the 
above protocol, demonstrating how timing information is brought back to the (abstract) protocol 
level (ie. Step 3 of Section 0 : 


1. A - 

B 

A 

2.B- 

-4 A 

{B,t B } Ka 

3. A- 

-> B 

“ ack ” at time t B — Sab — S B a 


In Message 2, instead of a nonce, B generates some random time value t B > Sab + S B a, 
concatenates it with B’s identity and encrypts the message with A’s public key. Then, B starts a 
timer t and sends the message. Upon reception, A extracts t B , waits time t B — Sab — S B a , and 
replies the single bit message u ack”. When B receives this message, the timer is stopped and B 
checks that t is sufficiently close to t B ; if so, A is authenticated to B. Of course, the amount of 
noise in the time measurements influences what we mean by “sufficiently close” above. Also, to 
be realistic, the length in bits of t B should be small enough, otherwise B would be waiting too 
long (on average); this would give an intruder the chance to guess t B , and answer the “acfc” at the 
appropriate time. Moreover, if encryption {•}. is deterministic, an attacker can record {B,t B }K A 
and the answers t B in a table. As soon as A chooses t B again (and this is likely since t B is small) 
and sends out {B,t B }K A , the attacker can notice the repeated message in its table since encryption 
is deterministic, and hence the attacker can intercept the message (so it never arrives to B) and still 
authenticate to A, since the attacker knows precisely when to send t B . Probabilistic encryption 
solves this issue, although even then the attacker can simply guess t B and violate authentication 
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with non-negligible probability. However, we can strengthen the protocol as follows: 


1. A- 

B 

A 

2. B - 

-> A 

{B,t B u ■ • • Ab^Ka 

3. A- 

-> B 

“ack ” at time ts x — Sab — Sba 

n + 3. A - 

■* B 

“ack ” at time — Sab — Sba 


For example, if is of length 4 bits, for i £ [l..n], then the total answer is n bits, in comparison 
with an answer of 4 n bits required in the nonce protocol. 

Of course, sending several short messages can be worse than sending one long message, in which 
case our protocol would not be so useful. In general, the value of n must be chosen as small as 
possible, depending on the desired security and network latency. A fast network allows us to reduce 
n and at the same time increment the length of f^, for i £ [l..n]. 

Intuitively, the sent times of the “acfc” ’s represent information, and the above protocols exploit 
that. To the best of our knowledge, this is a novel usage of time in security protocols. 

Application This protocol can be used to authenticate a whole chain of network packets, as 
follows. Suppose A has a large sequence of n packets which must be streamed to B over a network. 
For instance, these packets can represent an audio stream in the Internet. We want to authenticate 
the audio stream, but we do not wish to spend lots of resources on doing this. Let £ {Sab + 
Sba, Sab + Sba + C} for some constant C and Pi denote packet i, for 1 < i < n. Then the protocol 
becomes: 


l.A- 

-> B 

A , n 


2.5- 

A 

■ ■ ■ Ab u }k a 

3. A - 

■* B 

Pi at time 

- Sab - Sba 

n + 3. A- 

+ B 

p n at time ts n 

- Sab - Sba 


When tB i is Sab + Sba, it is the delay introduced by A is zero, ie. pi is sent right away. 
However, when ts t is Sab + Sba + C, the delay is C. To be as efficient as possible, C should be 
chosen to be the minimum amount of time that allows B to distinguish the delay modulated by A. 

In this protocol, only one bit is authenticated per packet. However, the larger the n is, the 
more confidence we can obtain of A’s authentication. 

Discussion In this protocol, we are in reality exploiting a well-known feature of channel coding: 
a so-called timing covert channel. In such a channel, the transmitting party modulates packets so 
that information can be passed even if its not allowed by the environment. Our usage differs in 
three ways: 

• Firstly, we use a mixed approach, in which some information is sent in the standard channel, 
and other is sent in the timing channel. 

• A second difference is more fundamental than the previous one. Our usage of the timing 
channel is purposely public, and there is no environment trying to stop the unauthorized 
information flow. Timing is used only because of its practical advantages, namely low- 
bandwidth. 

• Finally, in our protocol both communicating parties do not initially trust on the other’s 
identity, in principle: Indeed, ours is an authentication protocol. 
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6.2 Timing Leaks in an Implementation of the Private Authentication 
Protocol 

We now present a threat against an implementation of security protocols with branching: the 
so called timing attack. We illustrate this by showing an attack over a careless implementation 
of Abadi’s Private Authentication (PAP) protocol [2j (The second protocol). It is worthwhile 
to mention that the protocol has been proved correct by Abadi and Fournet ED, in a setting 
without time. We assume that each principal X has a set of communication parties Sx, listing 
the principals with whom X can communicate. The aim of the protocol is to allow an principal A 
to communicate privately with another principal B. Here “privately” means that no third party 
should be able to infer the identities of the parties taking part in the communication (i.e. A and 
B ) (PAP Goal 1). Moreover, if A wants to communicate with B but A ^ Sb , the protocol should 
also conceal B's identity (and presence) to A (PAP Goal 2). A run of the protocol in which A 
wants to communicate with B proceeds as follows: 

1. A generates a nonce N A - Then, A prepares a message M = {“hello” ,N a ,Ka}k b , and 
broadcasts {“hello”,M). 

2. When a principal C receives message {“hello”, M), it performs the following three steps: 

(a) C tries to decrypt M with its own private key. If the decryption fails, (which implies 
that C ^ B), then C creates a “decoy” message {N}k (creating a random K , and 
keeping AT -1 secret), broadcasts {“ack” ,{N}k) and finish its execution. If decryption 
succeeds, then C = B (and so from now on we will refer to C as B). B then continues 
to the next step. 

(b) B checks that A £ Sb- If this fails, i.e. A 0 Sb, then B creates a “decoy” message 
{N}k, broadcasts {“ack”, {N}k) and finishes execution. Otherwise B continues to the 
next step. 

(c) Finally, B generates a fresh nonce Nb, and broadcasts the message 
{“ack”,{“ack”,N A ,N B ,K B } KA ). 

It is interesting to see the use of “decoy” messages, to prevent attacks in which an intruder I 
prepares a message M = {“hello ”, Nc, Ka}k B i impersonating principal A. If decoy messages 
were not present, then I would send {“hello ”, M), and deduce whether A £ S B by noticing a 
response from B. However, using decoys only helps to confuse an attacker doing traffic analysis, 
and breaks down when considering a “timed” intruder, as we will show in the next section. 

An Attack Over an Implementation of the Private Authentication protocol 

We show an attack in which / can find whether A £ S B - The attack is illustrated in Figure ITfl 
where I is trying to attack A, B and C , which since I does not know their identities are called 
A, Y and Z. First, suppose that / qL S B (the attack for the case in which I £ S B is analogous). 
First / needs to know how long, on average, it takes to B to compute each step of the protocol as 
described above. To discover this I could prepare various messages: 

1. Firstly, I sends a message {“hello”,{N} k), where K is not the public key of any other 
participant. This would generate a number of decoy responses from the other participants, 
which I can time (Step 1 in Figure ITU for times x, y and z). 

2. Secondly, / sends a message {“hello ”, {“hello ”, A/, Kj}k b )- Again, this generates decoy 
responses from the other parties which I can time (Step 2 in the figure). However, if B 
is present, then one response will have longer time (ie. we get times x, z and y' with y' 
longer than y), reflecting the successful decryption and check that I £ S B performed by B 
(Recall we assume that I ^ S B )• Up to this point, I has information that allows him to 
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Step 1 : 


Sa = GC S B = GO s c = GO 





Figure 14: The attack over the PAP protocol, where X, Y and Z are unknown identities by the 
intruder I. A, B and C are real identities, with corresponding Sa , Sb and Sc sets; x, y, y', y" 
and z are timing values (Dashed circles indicate the intruder’s knowledge of inner values) 
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infer B 's presence (hence the dashed circle in the figure); Thus, this attack already violates 
goal 2 of Abadi’s requirements [2]: B should protect its presence if a party X is willing to 
communicate with B but X ^ Sb (Step 2). 

3. Finally, if B is present, then I sends message (“hello ”, {“hello ”, Nj, Ka}k b )- This would 
generate again the same decoy responses, except one that takes longer (Step 3 in the figure, 
for x, z and y" with y" longer than y'). If this response takes the same time as the above 
item, then I can deduce that A 0 Sb- Otherwise, if the response takes longer (reflecting the 
nonce generation Nb and encryption performed by B) then / can deduce that A € Sb- 

If I £ Sb, then the second step above returns the longest time, and the third message would 
take either less time or equal. 

After recording this information, / has three time values to, t\ and £ 2 - to corresponds to the time 
in which B is not present; t\ corresponds to the time in which B is present but its communicating 
party X ^ Sb- Finally, t 2 corresponds to the case in which B is present and its communicating 
party X € Sb- With these values at hand, now an attacker can check if A £ Sb for an arbitrary 
A. 

Timing in networks is often accurate but if the accuracy is too low, the intruder can repeat 
the timings (i), (ii) and (iii) and perform statistical analysis to increase the probability of the 
inferences to be correct m- We propose this as future work, when we have a probabilistic, timed 
model checker at disposal. 

7 Related Work 

Many approaches focus on the study of protocols that use timestamps US [H HZl E3 OH Recent 
work of Delzanno et.al. ESI presents an automatic procedure to verify protocols that use times¬ 
tamps, like the Wide Mouthed Frog protocol. In their work, differently from ours, a global clock 
is assumed, and timeouts and retransmissions are not discussed. Evans and Schneider m present 
a framework for timed analysis. Differently from our (UPPAAL) model checking, it is based on a 
semi-decision procedure with discrete time. In that work, the usage of retransmissions is hinted 
at as future work, but not (yet) addressed. Lowe [27] also analyses protocols with timing infor¬ 
mation; his work shares with us the model checking approach, although Lowe’s approach is based 
on a discrete time model. A global clock is also assumed, and timeouts nor retransmissions are 
addressed. Closer to ours is the work of Gorrieri et al. m, in which a real-time process algebra 
is presented for the analysis of time-dependent properties. They focus on compositionality results, 
and no model checking is presented. Gorrieri et al. also show how timeouts can be modelled, 
although retransmissions are not discussed. 

Regarding our timing attack upon Abadi’s protocol, Focardi et al m develop formal models 
for Felten and Schneider’s web privacy timing attack m ; their modelling activity shares with our 
work the idea of using timed automata for analysis, although our attack illustrates a timing attack 
over a “pure” security protocol. 


8 Conclusions 

Security protocol analysis is a mature field of research that has produced numerous results and 
valuable tools for the correct engineering of security protocols. Despite a large body of literature 
on the subject, most analysis methods do not take time into consideration (with the exception of 
a few papers, considering mainly the use of timestamps). We argue that this is not realistic as all 
distributed protocols need to implement timeouts (possibly followed by retransmissions). 

In this paper we address some of the issues that need to be considered when including time- 
related parameters in the engineering process of a security protocol. 
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Our first contribution is a method for the design and analysis of security protocols that consider 
timing issues. We model security protocols using timed automata, and use UPPAAL to simulate, 
debug and verify security protocols in a real time setting. To this end, we employ a general 
Dolev Yao style intruder (naturally encoded in UPPAAL), and we remark that modelling the 
intruder as a timed automata implicitly extends its power to take into account the time sensitivity. 
Our method allows us to specify security protocols in detail, with timeouts and retransmissions. 
This increases the confidence in the analysis, since the modelled protocols are closer to their 
implementations than the classical analysis (e.g. CASPER H7] or the constraint-based methods 
of ESI EDI)- 

Secondly, by analyzing the protocols in the Clark and Jacob library and the SPORE library, 
we see that most protocols schemas (w.r.t. timeouts) fit into a small number of common patterns. 
We analyse the efficiency and security of each of the patterns. Still, as possible future work we 
would like to perform a full UPPAAL analysis of each of these literature protocols (just as we do 
for Yahalom in Section im 

Other novel and more real-life protocols which are sensitive to timing issues (e.g. besides 
timeouts, use for instance puzzles) may benefit from our analysis, e.g. the Host-Identity-Protocol 
(HIP), initially analysed by Aura et al. |S]. 

Our third contribution is an illustration of the implicit information carried by timing. The mere 
act of sending a message at a specific moment in time, and not another, carries information. We 
propose a novel security protocol that exploits this fact to achieve authentication. The protocol 
replaces the standard nonces with timed challenges, which must be replied at specific moments in 
time to be successful. Although it is a preliminary idea, it exposes clearly the fact that security 
protocols can use and take advantage of time. 

Finally we address threats specifically involving timing should also be considered; specifically, 
timing attacks. We illustrate these attacks in the context of security protocols, where branching 
allows an intruder to deduce information that is intended to be kept secret. Specifically, we 
mount an attack over an imperfect implementation of Abadi’s private authentication protocol [2]. 
Solutions to avoid timing attacks in the implementations are usually expensive (e.g. noise injection 
or branch equalization), and it is not our purpose to investigate them. Here we merely lift the 
known problem of timing attacks, typically mounted against the cryptosystem to obtain secrets 
keys, to security protocols in general where the information leakage can be, in principle, anything. 

One possible direction of future work is to consider a timed and probabilistic model checker 
(in the lines of m or ED), that would allow us to study the protocols of Section 6. Moreover, a 
probabilistic setting would allow us to model, more realistically, the network latency. This, in turn, 
would provide us with a finer method to tune sensitive timing values. Another possible direction 
for future research would be to implement a compiler from a meta notation (similar to the standard 
notation, plus timing information) supporting symbolic terms, to UPPAAL automata. Ultimately, 
these directions of future work would contribute to a method of secure systems engineering. 
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Saptawijaya and the anonymous reviewers of FMSE2004 provided useful comments. 


References 

[1] Security Protocols Open Repository (SPORE). At http: //www. lsv. ens-cachan.fr/spore/ 
INRIA, March 2005. 

[2] M. Abadi. Private authentication. In R. Dingledine and P. F. Syverson, edi¬ 
tors, 2nd. Int. Workshop on Privacy Enhancing Technologies (PET), volume LNCS 
2482, pages 27-40, San Francisco, California, Apr 2002. Springer-Verlag, Berlin, 
http://www.springerlink.com/1ink.asp?id=t4wpgvurht!09gll 


21 



[3] R. Alur and D.L. Dill. A theory of timed automata. Theoretical Computer Science , (138):183- 
335, 1994. 

[4] T. Amnell, G. Behrmann, J. Bengtsson, P. R. D’Argenio, A. David, A. Fehnker, T. Hune, 
B. Jeannet, K. G. Larsen, M. O. Moller, P. Pettersson, C. Weise, and W. Yi. UPPAAL 
- Now, Next, and Future. In F. Cassez, C. Jard, B. Rozoy, and M. D. Ryand, edi¬ 
tors, J^th Summer School on Modeling and Verification of Parallel Processes (MOVEP), 
volume LNCS 2067, pages 99-124, Nantes, France, Jun 2000. Springer-Verlag, Berlin, 
http://www.springerlink.com/link.asp?id=8kmleyyvfqfm740f 

[5] T. Aura, A. Nagarajan, and A. Gurtov. Analysis of the hip base exchange protocol. In ACISP , 
pages 481-493, 2005. 

[6] G. Bella and L. C. Paulson. Kerberos version IV: Inductive analysis of the secrecy goals. In 
J.-J. Quisquater, editor, Proc. 5th European Symposium on Research in Computer Security , 
volume LNCS 1485, pages 361-375, Louvain-la-Neuve, Belgium, 1998. Springer-Verlag. 

[7] S. M. Bellovin and M. Merritt. Limitations of the kerberos authentication system. SIGCOMM 
Comput. Commun. Rev., 20(5):119-132, 1990. 

[8] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. ACM Transactions on 
Computer Systems , 8(l):18-36, 1990. 

[9] J. Clark and J. Jacob. A survey of authentication protocol literature: Version 1.0. 
http://www.cs.york.ac.uk/ jac/papers/drareview.ps.gz, 1997. 

[10] R. Corin and S. Etalle. An improved constraint-based system for the verification of security 
protocols. In M. V. Hermenegildo and G. Puebla, editors, 9th Int. Static Analysis Symp. 
(SAS), volume LNCS 2477, pages 326-341, Madrid, Spain, Sep 2002. Springer-Verlag, Berlin. 

[11] R. Corin, S. Etalle, P. H. Hartel, and A. Mader. Timed model checking of security protocols. 
In V. Atluri, M. Backes, D. Basin, and M. Waidner, editors, 2nd ACM Workshop on Formal 
Methods in Security Engineering: From Specifications to Code (FMSE), pages 23-32, Fairfax, 
Virginia, Oct 2004. ACM Press, New York. 

[12] C.J.F. Cremers, S. Mauw, and E.P. de Vink. Defining authentication in a trace model. In 
T. Dimitrakos and F. Martinelli, editors, Fast 2003 , Proceedings of the first international 
Workshop on Formal Aspects in Security and Trust, pages 131 -145, Pisa, September. IITT- 
CNR technical report. 

[13] P. R. D’Argenio, H. Hermanns, J.-P. Katoen, and J. Klaren. MODEST: A modelling language 
for stochastic timed systems. In L. de Alfaro and S. Gilmore, editors, Joint Int. Workshop on 
Process Algebra and Probabilistic Methods, Performance Modeling and Verification (PAPM- 
PROBMIV), volume LNCS 2165, pages 87 104, Aachen, Germany, Sep 2001. Springer-Verlag, 

Berlin, http://www.springerlink.com/link.asp?id=ka91rbfnj7g6a9dd 

[14] G. Delzanno and S. Etalle. Proof theory, transformations, and logic programming for de¬ 
bugging security protocols. In A. Pettorossi, editor, 11th Int. Logic Based Program Synthesis 
and Transformation (LOPSTR), volume LNCS 2372, pages 76-90, Paphos, Greece, Nov 2001. 
Springer-Verlag, Berlin, http: //www. cs .utwente . nl/"etalle/papers/de021opstr. pdf 

[15] G. Delzanno and P. Ganty. Automatic verification of time sensitive cryptographic protocols. 
In K. Jensen and A. Podelski, editors, Tools and Algorithms for the Construction and Analysis 
of Systems: 10th International Conference, TACAS 200f, Held as Part of the Joint European 
Conferences on Theory and Practice of Software, ETAPS 2004, pages 342 - 356, Barcelona, 
Spain, March 2004. Springer-Verlag, Berlin. 


22 



[16] D. Dolev and A. C. Yao. On the security of public key protocols. IEEE Transactions on 
Information Theory , 29(2):198-208, 1983. 

[17] E. English and S. Hamilton. Network security under siege: the timing attack. IEEE Computer, 
29(3):95-97, Mar 1996. http://www.computer.org/computer/col996/r3095abs.htm 

[18] N. Evans and S. Schneider. Analysing time dependent security properties in CSP using PVS. 
In F. Cuppens, Y. Deswarte, D. Gollmann, and M. Waidner, editors, ESORICS , volume LNCS 
1895, pages 222-237. Springer, 2000. 

[19] E. W. Felten and M. A. Schneider. Timing attacks on web privacy. In 7th ACM conference 
on Computer and communications security , pages 25-32, Athens, Greece, 2000. ACM Press, 

New York, http://doi.acm.org/10.1145/352600.352606 

[20] R. Focardi, R. Gorrieri, R. Lanotte, A. Maggiolo-Schettini, F. Martinelli, S. Tini, and 
E. Tronci. Formal models of timing attacks on web privacy. In M. Lenisa and M. Micu- 
lan, editors, Electronic Notes in Theoretical Computer Science , volume 62. Elsevier, 2002. 

[21] C. Fournet and M. Abadi. Hiding names: Private authentication in the applied pi calculus. 
In Symp. on Software Security , volume LNCS 2609, pages 317-338, Tokyo, Japan, Jan 2003. 
Springer-Verlag, Berlin, http: //www. springerlink. com/link.asp?id=2a24gfmwamq7metw 

[22] R. Gorrieri, E. Locatelli, and F. Martinelli. A simple language for real-time cryptographic 
protocol analysis. In P. Degano, editor, 12th European Symposium on Programming, ESOP 
2003, volume LNCS 2618, pages 114-128. Springer-Verlag, Berlin, 2003. 

[23] P. C. Kocher. Timing attacks on implementations of Diffie-Hellman, RSA, DSS and 
other systems. In N. Koblitz, editor, 16th Advances in Cryptology (CRYPTO), volume 
LNCS 1109, pages 104-113, Santa Barbara, California, Aug 1996. Springer-Verlag, Berlin, 
http://www.cryptography.com/resources/whitepapers/TimingAttacks.pdf 

[24] M. Kwiatkowska, G. Norman, and D. Parker. Probabilistic symbolic model checking with 
PRISM: A hybrid approach. In J.-P. Katoen and P. Stevens, editors, Proc. 8th Interna¬ 
tional Conference on Tools and Algorithms for the Construction and Analysis of Systems 
(TACAS’02), volume LNCS 2280, pages 52-66. Springer-Verlag, Berlin, 2002. 

[25] L. Lamport. Using time instead of timeout for fault-tolerant distributed systems. ACM 
Transactions on Programming Languages and Systems , 6(2):254-280, April 1984. 

[26] G. Lowe. An attack on the Needham-Schroeder public-key authentication protocol. Informa¬ 
tion Processing Letters, 56(3):131- 133, November 1995. 

[27] G. Lowe. Casper: A compiler for the analysis of security protocols. In Proc. 10th IEEE 
Computer Security Foundations Workshop (CSFW ’97), pages 18-30. IEEE, 1997. 

[28] J. Millen and V. Shmatikov. Constraint solving for bounded-process cryptographic protocol 
analysis. In Proc. 2001 ACM Conference on Computer and Communication Security, pages 
166 - 175. ACM press, 2001. 

[29] D. Mills. Cryptographic authentication for real-time network protocols. AMS DIMACS Series 
in Discrete Mathematics and Theoretical Computer Science, 45:135-144, 1999. 

[30] P. Syverson. A taxonomy of replay attacks. In Proceedings of the 7th IEEE Computer Security 
Foundations Workshop, pages 131 136, 1994. 

[31] S. Yovine. KRONOS: a verification tool for real-time systems. International Journal on 
Software Tools for Technology Transfer, 1(1/2): 123—133, 1997. 


23 



